Skip to main content

Introduction

EmpowerID utilizes an Attribute Flow Process to synchronize attributes between external systems and the EmpowerID Identity Warehouse. This synchronization ensures that identity data remains consistent and authoritative across multiple connected systems. The process operates using a hub-and-spoke methodology, where the Person Object serves as the central repository for attribute data. External systems contribute to and receive updates from this central identity store based on attribute flow rules, which define how, when, and in what direction data moves.

How Attribute Flow Works​

EmpowerID aggregates attributes from external systems into the Person Object, creating a master set of identity attributes. These attributes can originate from various sources, such as HR systems, directories like Active Directory, and cloud-based applications such as Salesforce. For example, HR might provide authoritative information like job title and department, while an Active Directory system may be authoritative for attributes like email address or manager.

EmpowerID Attribute Flow Hub and Spoke Paradigm

Once these attributes are aggregated into the Person Object, EmpowerID synchronizes updates outbound to external systems based on predefined rules. This ensures that changes made in authoritative sources propagate correctly, reducing inconsistencies across identity stores.

It's important to note that direct synchronization between external systems does not occur—all changes flow through the Person Object. This ensures that EmpowerID maintains control over attribute consistency and synchronization logic.

Levels of Attribute Flow Control​

EmpowerID allows for granular control over attribute flow, enabling administrators to define synchronization behavior at multiple levels. This control ensures that identity data is updated correctly while preventing unwanted modifications.

1. Attribute Flow Rules​

At the most detailed level, Attribute Flow Rules dictate how individual attributes are synchronized. These rules define:

  • The direction of synchronization: Inbound (external system to EmpowerID), Outbound (EmpowerID to external system), or Bidirectional (Last Change Wins).
  • Weighting scores: Used to resolve conflicts when multiple sources provide values for the same attribute.
  • Synchronization enablement: Allowing or disabling synchronization for specific attributes within an account store.

Attribute Flow Rules Page

For example, an HR system may be the authoritative source for employee job titles. An attribute flow rule can be configured to allow inbound updates for the title field, ensuring that any change in HR is reflected in EmpowerID and, subsequently, in downstream systems like Active Directory. If a system like Active Directory is instead authoritative for email addresses, an outbound rule can ensure that EmpowerID pushes email updates from the Person Object to AD.

Attribute flow rules are fundamental to maintaining data consistency and preventing conflicts between sources. For instance, a Bidirectional rule (Last Change Wins) could be applied to an attribute like a phone number, allowing updates from either an external system or EmpowerID, with the most recent change becoming the authoritative value.

2. Account Store Settings​

At a broader level, attribute flow can be controlled at the account store level. Each external system integrated with EmpowerID is represented as an account store, and administrators can configure settings to enable or disable attribute synchronization for the entire account store in the account store definition by checking or unchecking the box labeled Allow Attribute Flow.

3. System-Level Attribute Flow Control​

At the highest level, EmpowerID allows attribute flow processing to be managed globally. This is done by enabling or disabling the Attribute Flow Directory Change Processor Job. This job is responsible for executing all attribute synchronization transactions.

Disabling the job stops all attribute flow processing system-wide, effectively pausing updates until it is re-enabled. This is particularly useful in scenarios such as:

  • Performing major configuration changes to attribute flow rules.
  • Conducting an audit of inbound and outbound attribute changes.
  • Validating synchronization behavior before applying updates.

When the Directory Change Processor Job is turned off, inventory processes still collect attribute changes and queue them in the Attribute Flow Inbox/Outbox tables. However, these queued updates are not processed until the job is re-enabled. This mechanism allows administrators to review pending changes before committing them, ensuring that attribute flow behaves as expected.

Beyond these three levels of control, EmpowerID provides additional customization options, including custom attribute flow handlers, schema mappings, and attribute transformation logic. These advanced capabilities allow organizations to tailor attribute synchronization to their specific operational and compliance needs.

Attribute Flow Rules and Synchronization Settings​

Attribute flow rules define the direction and precedence of attribute synchronization and are critical to ensuring that identity attributes are consistently updated across systems.

Flow Directions:​

  • Inbound: Attributes flow from an external system into the Person Object in EmpowerID. This is used when the external system is authoritative for the attribute.
  • Outbound: Attributes flow from the Person Object in EmpowerID to an external system. This is used when EmpowerID is authoritative for the attribute.
  • Bidirectional (Last Change Wins): The attribute can be updated in both EmpowerID and the external system, with the most recent change becoming authoritative.
  • Disabled: Synchronization is turned off for a specified attribute, meaning no updates will be processed after the initial provisioning.

Attribute Flow Control by System Type​

For each account store (such as Active Directory, HR systems, or cloud applications), attribute flow rules determine which system is authoritative for specific attributes. For example:

  • HR Systems are often authoritative for job titles, departments, and employment status.
  • Active Directory may be authoritative for email addresses, manager relationships, and group memberships.
  • Cloud applications like Salesforce or Workday may contribute attributes like user roles, profile URLs, or external IDs.

Initial Provisioning vs. Ongoing Synchronization​

Even when attribute flow is disabled for an attribute, initial provisioning ensures that attributes are populated at the time of account creation. However, ongoing updates will not be synchronized unless attribute flow is explicitly enabled for the attribute.

For example, if department attribute flow is disabled for an account store, EmpowerID will still write the department value to the external system when a new account is provisioned. However, any subsequent updates to the department in EmpowerID will not be synchronized to the external system.

Attribute Flow and Conflict Resolution​

Conflicts can arise when multiple systems provide values for the same attribute. To resolve these conflicts, EmpowerID uses attribute flow scores that define precedence for attribute updates. Each system providing attribute values can be assigned a:

  • Create Score – Determines which system wins when an attribute is initially populated.
  • Update Score – Determines which system wins when an attribute is modified.
  • Delete Score – Determines whether an attribute should be deleted when it is removed from an external system.

For example, an HR system may provide an initial phone number with a create score of 50, while a corporate phone system may provide updates with an update score of 55. This ensures that initial onboarding data comes from HR, but the more current number from the phone system updates the record later.

Understanding and configuring these rules ensures seamless attribute synchronization across systems while preventing unwanted attribute overwrites.

Attribute Flow Scoring and Conflict Resolution​

To resolve conflicts when multiple sources are authoritative for an attribute, EmpowerID uses a scoring system that determines which system takes precedence in different scenarios. This ensures that the most reliable source provides attribute updates while avoiding unintended overwrites.

Scoring Mechanism:​

  • Create Score: Determines which source is authoritative when setting an attribute for the first time.
  • Update Score: Determines which source is authoritative when updating an existing attribute.
  • Delete Score: Determines whether a blank or missing attribute in an external system should delete the existing value in the Person Object.

EmpowerID’s Attribute Source Tracking​

EmpowerID maintains detailed records of which system last updated each attribute. This allows the system to make intelligent decisions about whether to overwrite, retain, or delete an attribute based on source authority and scoring rules. Every time an attribute is updated, EmpowerID logs the originating system, ensuring that conflicts can be properly managed.

For example, if an HR system updates a job title, and later an Active Directory system attempts to change the same attribute, EmpowerID can reference the last authoritative update source and determine whether the change should be applied based on scoring rules.

Examples of Attribute Scoring in Action​

Example 1: Handling Conflicting Phone Numbers​

Consider a scenario where a new employee’s phone number is provided by two different systems:

  • HR System provides an initial phone number with a create score of 50.
  • Corporate phone system later updates the phone number with an update score of 55.

EmpowerID tracks that HR provided the initial value. When the corporate phone system submits an update, EmpowerID sees that it has a higher update score and allows the change, ensuring the most recent and authoritative value is stored.

Example 2: Department Attribute Synchronization​

In some organizations, the department attribute is managed by multiple systems. Suppose:

  • HR System has an update score of 60.
  • Active Directory has an update score of 45.

If a department change occurs in HR, EmpowerID ensures that the HR system’s update is applied to the Person Object. If an administrator manually changes the department in Active Directory, EmpowerID detects the lower update score and prevents it from overriding the HR-provided value.

Example 3: Manager Attribute Flow with Deletion Control​

A user’s manager is stored in both HR and Active Directory:

  • HR system sets the manager attribute with an update score of 70 and a delete score of 80.
  • Active Directory has an update score of 60 and a delete score of 40.

If the manager attribute is removed from HR, the high delete score ensures that EmpowerID also removes the manager assignment from the Person Object. However, if Active Directory removes the manager attribute, the lower delete score prevents it from removing the manager in EmpowerID, as HR is the authoritative source.

Ensuring Data Consistency with Scoring Rules​

By leveraging create, update, and delete scores and tracking the origin of updates, organizations can enforce clear policies on how identity attributes are maintained. EmpowerID ensures that authoritative sources dictate changes while preventing undesirable updates from less authoritative systems.

Schema Mapping and Security Boundary Attributes​

EmpowerID uses a schema mapping model to translate and correlate attributes across different systems. This mapping ensures that attributes from various external sources align correctly with the Person Object in EmpowerID, providing consistency in identity management.

Security Boundary Attributes and Object Attributes​

EmpowerID utilizes two key concepts in schema mapping:

  • Security Boundary Attributes: These are attributes from external systems, such as HR systems, Active Directory, or cloud-based applications.
  • Object Attributes: These serve as intermediary mapping object that serves as the referencial link between the Security Boundary Attributes.

Relationship Between Security Boundary Attributes and Object Attributes

How Security Boundary Attributes Relate to Object Attributes​

Each external system has its own schema for storing identity attributes. For example:

  • An HR system may store job title as JobTitle.
  • Active Directory may store it as title.
  • A cloud-based CRM may store it as positionTitle.

Since each system may name and structure attributes differently, EmpowerID uses Object Attributes as a standardized reference point. Security Boundary Attributes from different external systems map to a common Object Attribute, ensuring that all data sources align to a single, consistent representation of the attribute.

For instance, EmpowerID has an Object Attribute called JobTitle, and maps multiple Security Boundary Attributes to it:

  • HRSystem.JobTitle → JobTitle
  • AD.title → JobTitle
  • CRM.positionTitle → JobTitle
  • EmpowerID.Title → JobTitle (The security boundary attribute for the EmpowerID Person)

This mapping ensures that EmpowerID can maintain a unified and authoritative value for attributes across all connected systems.

Schema Mapping Example​

Suppose an organization integrates an HR system, Active Directory, and Salesforce. The Department attribute might be stored differently:

  • HR System: HR_Department
  • Active Directory: department
  • Salesforce: departmentName

By mapping these attributes to a common Object Attribute in EmpowerID called Department all systems reference a common object attribute, improving consistency and synchronization accuracy.

This schema mapping model allows EmpowerID to:

  • Standardize attributes across different sources.
  • Define clear mappings for identity attributes.
  • Enforce consistent and structured attribute flow logic across systems.